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SECTION  I 


INTRODUCTION 


PMSS  DESCRIPTION 

The  DMSS  simulates  the  avionics  sensors,  weapon  subsystems,  and 
aircraft/environment  in  the  performance  of  a  Close  Air  Support  (CAS)  mission 
during  demonstrations  of  the  Digital  Avionics  Information  System  (DAIS).  An 
overview  of  the  DMSS  is  presented  in  Figure  1. 

DMSS  is  presently  hosted  on  a  DECsystem-10  as  part  of  the  Avionics 
System  Analysis  and  Integration  Laboratory  (AVSAIL)  facility  required  to 
support  a  laboratory  demonstration  of  DAIS.  The  facility  includes  a 
realistic  cockpit  mock-up  with  the  core  elements  of  DAIS  operating  as  they 
would  in  an  aircraft.  The  key  items  of  the  support  equipment  are  the 
mission  software  processors  and  their  resident  software  which  provide  the 
test  control,  monitoring,  and  responses  necessary  to  perform  the  DAIS 
demonstration. 

The  DMSS  simulates  the  aircraft,  environment,  and  various  sensors 
and  weapons;  as  well  as  co-ordinating  the  Heads  Up  Display  and 
out-the-wi ndow  scene.  The  main  function  of  the  DMSS  is  to  respond  to 
cockpit  controls  and  mission  software.  Other  functions  which  DMSS  can 
perform  are: 

(1)  Log  simulation  data  for  post-run  analysis; 

(2)  Snapshot  simulation  system  variables;  and 

(3)  Reset  simlation  variables  to  snapshot  values. 

The  DMSS  consists  of  the  following  seven  functional  types  of 
software  and  their  subsets  as  follows: 
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(1)  Executive  software  -  responsible  for  control  of  the  simulation. 

(2)  Sensor  Models  -  simulate  the  following  aircraft  sensors: 

•  Air  Data  Computer  (ADC); 

•  Radar  Altimeter  (RADALT); 

•  Tactical  Air  Navigation  System  (TACAN); 

•  Inertial  Navigation  Unit  (INU); 

•  Laser  Ranger  (LSR) ; 

•  Instrument  Landing  System  (ILS); 

•  VATS/Pave  Tack  (PAVTAC);  and 

•  Pave  Penny  (PAVPEN). 

(3)  SLU/Stores  Models  -  simulate  a  MK-82  low  drag  general  purpose 
weapon  system  (MK82)  and  the  Maverick  Missle  (MAVRIK),  and  also 
scores  possible  hits  on  demonstration  targets. 

(4)  Aircraft/Environment  Models  -  provide  A-7  airframe  dynamics, 
flight  control  dynamics,  and  propulsion  information  through  the 
fol  lowing: 

•  Airplane  Model  (AIRPLN); 

•  Earth  Model  (EARTH);  and 

•  Atmosphere  Model  (ATMO). 

(5)  Interface  Utilities  -  provide  access  to  the  Crew  Station 
Cockpit  controls  and  displays,  and  to  the  Evans  and  Sutherland 
Picture  System  via  the  following: 

•  Cockpit  Switches  (COCKPT); 

•  Controls  (CNTRLS); 

•  Instruments  (INSTRM); 

•  HUD/Evans  and  Sutherland  Picture  System  (HUDES);  and 
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•  Three-Dimensional  Background  (BKGR3D). 

(6)  Data  logging  -  records  data  during  simulation.  The  data  logged 
can  be  analyzed  using  Data  Reduction  and  Analysis  Software 
and/or  VIEW  after  termination  of  the  simulation. 

(7)  Checkpoint/Reset  -  provides  the  capibility  to  reset  the 
scenario  during  both  real-time  and  non-real-time  system 
operation . 

OBJECTIVES 

With  the  increasing  cost  of  software  development,  the  availability 
of  a  system  as  versatile  as  the  DMSS  can  reduce  costs  by  being  transferred 
into  a  general  library  where  several  organizations  can  use  it  to  its  fullest 
potential.  With  updated  documentation,  improved  source  code,  and  training 
classes  to  familiarize  users  with  the  capabilities  of  this  powerful 
simulation  system,  the  longevity  of  DMSS  could  be  increased.  However,  prior 
to  this  effort  DMSS  was  not  properly  documented,  easily  maintainable,  or 
transportable. 
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SECTION  II 


BACKGROUND 


DMSS  EVOLUTION 

The  DMSS  experienced  a'  history  of  growth  which  during  several 
different  groups  implemented  and  maintained  a  common  software  system.  In 
cases  such  as  this,  the  overall  performance  of  the  software  was  potentially 
undermined  with  errors,  lack  of  speed,  and  excessive  core  useage.  Problems 
with  such  "adopted"  code  were  non-uniform  design  and  documentation 
practices,  which  subsequently  lead  to  interface  and  maintenance  problems. 

The  DMSS  increased  in  size  and  complexity  to  support  the  expanding 
requirements  of  DAIS  concept  demonstrations  and  feasibility  analyses.  As 
new  missions  evolve  with  increased  model  requirements,  the  core  size  and 
execution  time  metrics  become  critical  factors.  The  continued  long  term 
usefulness  of  the  DMSS  is  enhanced  through  a  combined  effort  of  optimization 
and  thorough  documentation.  The  ultimate  value  of  a  software  system  is 
determined  not  only  by  how  well  the  software  works,  but  by  how  well  it  is 
documented,  how  easily  it  is  modified,  and  how  readily  it  is  transferred. 

The  DMSS  evolved  from  several  different  aircraft  simulation  efforts. 
Some  of  the  models  were  provided  by  General  Dynamics,  some  were  modified 
Naval  Weapons  Center  models  implemented  by  SCI,  while  other  have  been 
developed  by  yet  other  contractor  and  government  personnel.  Additionally, 
the  DECsystem-10  operating  system  contains  non-standard  executive  and 
utility  routines  specially  designed  for  the  facility.  This  "conglomeration" 
of  source  code  was  documented  during  early  1977.  At  that  time  some  routines 
were  found  to  be  poorly  organized  and  had  some  obvious  errors  or  extraneous 
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code. 


OBJECTIVE  OF  THE  EFFORT 

The  principal  objective  of  the  effort  was  to  provide  AFWAL  with  a 
fully-documented,  easily  maintained,  adaptable,  and  portable 
aircraft/sensor/environment  simulation  system.  The  attainment  of  this 
objective  would  significantly  enhance  the  value  of  the  DMSS  by  ensuring 
continued,  long-term  use  by  other  laboratory  activities  and  future  system 
program  offices.  Subsets  of  this  objective  include  the  development  of  new 
models,  optimization  of  existing  software,  training,  and  complete,  accurate 
documentation  of  all  DMSS  code. 

SCOPE  OF  THE  EFFORT 

The  scope  of  this  effort  addressed  the  following  general  task  areas: 

•  The  addition  of  the  new  models  needed  for  the 
demonstration  missions  (VATS/Pave  Tack  and  the 
Maverick  Missile). 

•  Enhancing  the  existing  software  for  increased 
efficiency,  maintainability,  and  portability. 

•  Providing  the  Air  Force  with  current  and 
meaningful  documentation. 

•  Providing  comprehensive  training. 

Through  updating  of  the  DMSS  software  for  efficiency  and  portability 
and  developing  current,  accurate,  and  useful  users'  documentation,  DAIS 
mission  demonstrations  will  be  facilitated.  Continued,  long-term  usefulness 
of  the  DMSS  will  also  be  ensured.  The  general  task  areas  discussed  in  this 
section  are  presented  in  more  detail  in  subsequent  sections  of  this  report, 
which  is  organized  as  follows: 
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•  Section  III,  Technical  Approach  -  describes  the  method¬ 
ology  used  in  this  effort  to  accomplish  the  objective 
outlined  in  this  section. 

•  Section  IV,  Deviations/Modifications  -  details  any 
deviations/modifications  from  original  technical  effort 
and  rationale  for  the  changes. 

•  Section  V,  Observations  and  Recommendations  -  contains 
observations  made  during  the  course  of  the  effort  which 
relate  to  the  current  and  future  DMSS.  Recommendations 
are  also  provided  relative  to  future  candidate 
modifications  and  enhancements. 
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SECTION  III 


TECHNICAL  APPROACH 


OVERVIEW 

The  DMSS  Software  Support  effort  had  two  principal  objectives.  The 
first  was  to  provide  AFWAL  with  a  fully  documented,  maintainable,  adaptable, 
and  portable  aircraft/sensor/environment  simulation  system.  The  second  was 
to  provide  a  system  of  enhanced  capabilities  and  value  to  ensure  that  future 
DAIS  mission  demonstrations  are  facilitated.  The  objectives  of  the  effort 
were  met  by  applying  sound  and  proven  system  engineering  practices.  The 
approach  included: 

•  Portability  and  ease  of  maintenance  through  well 
structured  design,  coding,  and  documentation. 

•  Up-to-date  documentation  of  the  present  DMSS,  new 
models,  and  modifications. 

•  Coordination  and  liaison  with  DAIS,  System  Integration 
and  Test  Coordination  contractor  (SITC),  and  other 
contractors  and  users. 

•  Comprehensive  reports  and  briefings  informing  the  Air 
Force  of  the  status  and  results  of  the  contract. 

Task  1  (Models  Development)  was  accomplished  to  augment  the 
capability  of  the  present  DAIS  facility.  Models  of  a  Maverick  (AGM-65A) 
television  guided  tactical  missile  and  the  VATS/Pave  Tack  laser  designator 
pod  were  developed  and  incorporated.  This  process  followed  a  multi-step 
procedure  consisting  of  the  following  subtasks: 

•  Design,  during  which  top-level  and  detailed  flowcharts 
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are  made  and  revised  as  necessary; 

•  Coding  and  Checkout,  during  which  the  detailed 
flowcharts  are  transcribed  into  ANSI  FORTRAN  IV  and  the 
logic  verified; 

•  Testing  on  a  multi-step  basis  to  ensure  the  model 
operates  as  required;  and 

•  Maintenance  as  needed  to  ensure  compliance  with 
Configuration  Control  Board  (CCB)  directives. 

The  software  methodology  and  standards  followed  for  development  of 
the  models  were  detailed  in  the  Software  Management  Plan.  Figure  2 
graphically  depicts  the  process  implemented  during  new  model  development. 

During  Task  2  (DMSS  Enhancement)  and  concurrently  with  the 
development  of  the  new  models,  the  existing  DMSS  software  was  analyzed  to 
determine  the  steps  to  be  taken  to  optimize  efficiency,  enhance 
maintainability,  and  promote  transferability. 

A  prioritized  list  of  DMSS  software  components  (executive,  models, 
and  utilities)  to  be  enhanced,  was  established  base  up on: 

(1)  analysis  of  the  current  DMSS  configuration  and  operation;  and 

(2)  previous  performance  evaluations  made  by  the  SITC  contractor. 
Figure  3  depicts  the  enhancement  process  implemented  during  Task  2. 

During  Task  3  (Documentation  Update),  two  principal  objectives  were 
accompl ished: 

(1)  The  existing  DMSS  Part  II  Specification  and  other 
associated  documents  were  revised;  and 

(2)  New  documents  were  developed  as  required. 
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All  documentation  was  accomplished  in  accordance  with  MIL-STD-483  and 
MIL-STD-490.  Documentation  tasking  was  accomplished  concurrently  with  new 
model  development  and  enhancement  tasking. 

Task  4  (Software  Management  Plan)  provided  the  Air  Force  with 
visibility  into,  and  control  over,  the  complete  production  and  documentation 
of  all  software  resulting  from  the  DMSS  Software  Support  Contract.  The 
function  accomplished  by  the  Software  Management  Plan  was  to  ensure  that  the 
technical  objectives  of  the  contract  were  met  in  a  timely  and  cost-effective 
manner. 

During  Task  5  (Integration  and  Testing),  software  personnel  were 
responsible  for  the  integration  of  the  Maverick  and  VATS/Pave  Tack  models 
into  the  system  and  the  subsequent  testing  of  the  system.  The  integration 
and  testing  process  ensured  the  compatibility  of  the  models  with  their 
respective  Interface  Control  Document  descriptions.  The  integration  and 
testing  activities  ensured  that  the  new  models  and  the  enhanced  executive 
and  models  performed  their  respective  functions  in  a  precise  and  timely 
manner. 

A  Computer  Program  Test  Plan  was  prepared  for  each  new  model  and  the 
total  DMSS  in  draft  form.  Test  Reports  for  each  new  model  and  the  total 
DMSS  were  delivered.  These  reports  primarily  addressed'  the  test  results 
(expected  vs.  actual)  and  recommendations  for  future  action  based  upon 
these  test  results. 

Task  6  (Engineering  Services)  involved  software  engineering  support 
being  provided  to  the  Models  Development  Task  as  required.  This  support 
involved  management,  technical,  and  engineering  support  and  services. 

Task  7  (Liaison  and  Coordination)  was  included  to  promote 
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understanding  and  coordination  on  an  informal  day-to-day  basis.  It 
accomplished  the  following: 

•  A  close  working  relationship  with  the  AF  Program 
Manager;  and 

•  Soliciting  of  inputs,  opinions,  and  feedback  throughout 
all  phases  of  the  effort.  Cross  feedback  between 
contractors  on  documents,  plans,  etc. 

Task  8  (Training)  ensured  the  continuation  of  an  organic  capability 
within  the  Air  Force  with  regard  to  DMSS  operation  and  maintenance,  and  also 
served  to  familiarize  outside  organizations  with  DMSS  capabilities  at  both 
the  system  and  module  levels.  SCI  provided  comprehensive  training  using  a 
combination  of  detailed  training  materials,  lectures,  and  meaningful 
laboratory  exercises. 

Task  9  (Program  Management)  ensured  the  continuity  and  visibility 
required  by  an  effort  of  the  size  and  complexity  of  the  DMSS  Software 
Support  contract.  Specific  areas  encompassed  by  this  effort  included: 

•  Technical  Reporting; 

•  Schedule  Reporting; 

t  Physical  Configuration  Audits;  and 

•  Adherence  to  Standards. 

Detailed  descriptions  of  the  efforts  conducted  under  each  of  the 
tasks  described  are  presented  in  the  following  paragraphs. 
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TASK  1  -  MODELS  DEVELOPMENT 

The  development  of  the  documentation  and  software  for  the  DMSS  was 
accomplished  in  accordance  with  the  Software  Management  Plan  developed 
during  Task  4.  While  the  development  of  the  Plan  was  accomplished  in  Task 
4,  in  actuality  it  was  one  of  the  initial  efforts  completed  by  SCI  in  order 
to  have  it  available  prior  to  the  software  development  effort.  The 
following  subparagraphs  detail  the  various  steps  implemented  during  the 
models  development  task. 

Design 

During  this  subtask,  personnel  analyzed  the  existing  development 
specification  (SA  211  203,  Part  I)  for  the  Maverick  and  VATS/Pave  Tack 
simulation.  The  required  interfaces  with  other  DMSS  software  were 
investigated  and  the  details  concerning  the  two  new  models  were  verified 
with  DAIS  and  SITC  personnel. 

Throughout  the  requirements  analysis,  pertinent  data  was  summarized 
in  a  software  development  notebook.  An  initial  design  for  each  model,  in 
the  form  of  algorithms  and  flowcharts,  was  generated  and  subjected  to 
detailed  review  by  other  members  of  the  project  team.  A  Preliminary  Design 
Review  (PDR)  was  conducted  to  ensure  that  the  basic  design  approach  met  Air 
Force  specifications.  The  overall  risks  associated  with  each  model  were 
reviewed  on  a  technical,  cost,  and  schedule  basis.  Fifteen  days  prior  to 
the  PDR,  the  Air  Force  Program  Manager  was  furnished  with  the  design  review 
package  for  review. 

The  draft  Part  II  Specification  for  each  model  was  developed  for 
presentation  to  the  Air  Force  thirty  days  prior  to  the  Critical  Design 
Review  (CDR).  At  the  CDR,  the  draft  Part  II  Specification  and  other  design 
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data  for  each  model  were  analyzed  to  ensure  that  the  proposed  design 
solution  satisfied  the  performance  requirements  established  by  the 
development  specification.  The  review  process  ensured  that  any  design 
modification  established  at  the  PDR  had  been  incorporated.  The  interfaces 
between  the  new  models  and  other  DMSS  software  were  reviewed  for 
compatibility. 

As  a  result  of  the  CDR,  the  draft  Part  II  Specification  was  revised 
and  a  draft  version  was  issued.  The  final  Part  II  Specification  was 
delivered  at  the  Preliminary  Configuration  Audit  (PCA).  The  following 
sections  describe  the  design  approach  for  the  Maverick  and  VATS/Pave  Tack 
Models.  The  guidelines  presented  in  the  Software  Management  Plan  were 
followed  throughout  their  design. 

Maverick  Simulation 

At  the  outset  of  designing  the  Maverick  simulation  software  a 
requirements  analysis  was  conducted.  The  analysis  detailed  the  high  risk 
and  critical  design  requirements,  along  with  the  interfaces  required  between 
the  software  and  hardware.  A  top-down  design  methodology  was  followed  to 
provide  traceability  and  facilitate  software  verification. 

Inputs  from  DAIS  Mission  Software  utilized  in  the  Maverick 
simulation  included: 

•  Elevation  steering  command; 

•  Azimuth  steering  command; 

•  Gyro  spin-up  power  reset  message; 

•  Master  reset  message; 

•  PAL /SAFE /MONF  message; 

•  Option  select  message; 


•  Arm  1  sequence; 

•  Arm  2  sequence; 

•  Videc/Power/Rack  control  message;  and 

•  Release  message. 

Three  sets  of  variables  were  used  with  the  Maverick  simulation:  (1) 
input  variables  which  provide  information  from  mission  software  and  other 
simulation  routines;  (2)  internal  variables  which  are  necessary  with  the 
Maverick  routines  to  simulate  missile  operation;  and  (3)  output  variables 
which  are  used  by  mission  software  and  other  routines. 

Some  of  the  variables  utilized  within  the  Maverick  model  to  simulate 
the  operation  of  tne  missile  included: 

•  Missile  f ield-of-view; 

•  Missile  gimbal  limits; 

•  Missile  slew  rate; 

•  Missile  signal-to-noise  ratio  for  lock-on  and  launch;  and 

•  Gyro  spin-up  time. 

The  simulation  outputs  a  monitor  message  to  the  mission  software  which 
describes  the  appropriate  action  to  be  taken.  The  functional  interfaces 
between  these  variables  and  other  software  were  detailed  in  the  software 
development  notebook.  This  notebook  was  used  as  a  guide  for  coding, 
checkout,  documentation,  testing,  ind  maintenance.  Figure  4  depicts  the 
top-level  Maverick  design  proposed  and  approved  during  this  effort. 

The  simulation  of  the  Maverick  can  display  to  the  pilot  a  set  of 
crosshairs,  representing  the  center  line  of  the  AGM-65A  five  degree 
f ield-of-view,  and  a  target  image  on  a  graphics  display.  The  elevation  and 
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Figure  4 
Maverick  Model 
Top  Level  Flowchart 


azimuth  steering  commands  generated  by  mission  software  slews  the  missile 
camera's  1 ine-of-sight  (LOS).  The  gimbal  limits  of  the  Maverick  are  checked 
to  ascertain  if  they  have  been  reached  or  exceeded,  and  the  position  of  the 
target  within  the  missile's  f ield-of-view  were  calculated  based  on  the 
aircraft's  position  relative  to  the  target  on  a  flat  earth  surface.  The 
target  image  is  driven  based  on  these  calculations.  Once  the  target  is 
centered  in  the  crosshairs  and  designated,  the  simulation  keeps  the  target 
centered  unless  the  aircraft  causes  the  simulated  AGM-65A  head  to  reach  the 
gimbal  limits.  Detailed  flowcharts  of  this  operation  were  developed  and 
updated  as  required  during  performance  of  subsequent  phases  of  model 
development . 

VATS/Pave  Tack  Simulation 

The  VATS/Pave  Tack  simulation  is  one  part  of  the  Sensor  Simulation 
that  models  on-board  aircraft  sensors.  At  the  outset  of  designing  the 
VATS/Pave  Tack  simulation  software,  a  requirements  analysis  was  conducted. 
The  analysis  detailed  the  high  risk  and  critical  oesign  requirements,  along 
with  the  interfaces  required  between  the  software  and  hardware.  A  top-down 
methodology  was  followed  to  provide  traceability  and  facilitate  software 
verification.  Figure  5  graphically  portrays  the  VATS/Pave  Tack  top-level 
design  utilized  in  developing  this  model. 

Three  sets  of  variables  were  used  with  the  VATS/Pave  Tack 
simulation:  (1)  input  variables  which  provide  information  from  mission 
software  and  other  simulation  routines;  (2)  internal  variables  which  are 
necessary  within  VATS/Pave  Tack  routines  to  simulate  pod  operation;  and  (3) 
output  variables  which  are  used  by  mission  software  and  other  routines. 
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T 


PAVE  TACK 
EXECUTIVE 


Figure  5 

VATS/PAVE  TACK  Top  level  Flowchart 


Some  of  the  inputs  from  other  DMSS  software  and  DAIS  Mission  Software 
utilized  in  the  VATS/Pave  Tack  simulation  included: 

•  Mode  Command  -  Off,  Bite,  Standby,  Cue,  or  Track; 

•  Direction  Cue  -  the  cue  is  sent  in  the  form  of  the 
north,  east,  and  vertical  components  of  the  range  to  the 
reference  LOS; 

•  Aircraft  Velocity  -  north,  east,  and  vertical  components 
of  ground  speed;  and 

•  Aircraft  Attitude  -  yaw,  pitch,  and  roll  angles. 

Some  of  the  variables  used  within  the  VATS/Pave  Tack  Model  to 
simulate  the  operation  of  the  pod  included  gimbal  angles  and  f ield-of-view. 
The  outputs  from  the  model  to  mission  software  included: 

•  Mode  Status  -  indication  of  the  current  mode; 

•  Bite  Response  -  go  or  no-go  discrete; 

•  Track  Discrete  -  discrete  indicating  the  system  is 
tracking; 

•  LOS  direction  cosines  relative  to  aircraft  body;  and 

•  Slant  range. 

The  functional  interfaces  between  these  variables  and  other  software  were 
detailed  in  the  software  development  notebook.  This  notebook  was  used  as  a 
guide  for  coding,  checkout,  documentation,  testing,  and  maintenance. 

Coding  and  Checkout 

Upon  completion  of  the  respective  CDR,  the  coding  of  the  Maverick 
and  VATS/Pave  Tack  models  was  initiated.  The  flowchart  and  algorithms  i r. 
the  software  development  notebook  and  preliminary  Part  II  Specifications 
were  the  bases  for  developing  the  actual  code.  The  coding  followed  a 
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structured  program  logic  flow  to  facilitate  testing,  maintenance,  and 
documentation.  By  using  top-down  design  techniques,  portions  of  the  models 
were  checked  out  independently  for  correctness.  The  coding  was  accomplished 
in  RATFOR  (Rational  FORTRAN)  on  the  AFWAL  AVSAIL  DECsystem-10.  Meaningful 
comments  were  inserted  during  the  coding  process  to  facilitate  future 
software  maintenance. 

Before  beginning  formalized  testing,  all  logic  of  the  individual 
routines  within  the  models  was  checked  out,  as  was  the  entire  model  in  a 
stand-alone  configuration.  This  was  accomplished  by  developing  test  drivers 
and  checking  out  the  individual  routines  prior  to  integration.  Desk  top 
checkouts  were  also  conducted  by  software  personnel  to  isolate  more  obvious 
deficiencies  prior  to  actual  model/system  tests. 

Testing 

During  the  design  of  the  models,  a  test  plan  for  each  model  was 
developed.  The  test  plan  was  delivered  to  the  Air  Force  Program  Manager 
prior  to  the  PDR.  This  ensured  that  the  programs  would  support  the  various 
levels  of  testing  required.  The  testing  was  performed  on  two  levels  for 
each  model : 

•  Stand-alone  mode  and 

•  Interface  and  functional  testing 

Test  results  were  reported  to  the  Air  Force  Program  Manager.  The 
draft  Part  II  Specifications  and  User':  manuals  were  completed  and  formal 
delivery  of  the  models  and  their  supporting  documentation  made  to  the  System 
Integration  Branch.  After  acceptance  by  the  Air  Force  Program  Manager  and 
SITC  contractor,  the  product  baseline  models  were  placed  under  formal 
configuration  control. 
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TASK  2  -  DMSS  ENHANCEMENT  Due  to  the  size  of  the  DMSS  software  system,  the 
routines  were  analyzed  on  a  priority  basis  to  ensure  that  available  time  and 
funds  were  effectively  used  to  upgrade  the  existing  software.  The  routines 
were  ordered  in  a  prioritized  list,  highlighting  those  routines  whose 
optimization  would  most  significantly  improve  DMSS  performance.  The  first 
step  in  this  task,  involved  finalizing  the  prioritization  criteria  which 
included  the  following: 

•  Memory  utilization  (larger  programs  were  given  high 
priority) ; 

•  Iteration  rate  (higher  iteration  rates  were  given 
greater  priority); 

•  Frame  loading  (heavy  frame  loading  were  given  higher 
priority);  and 

•  Total  routine  execution  time  as  a  percentage  of  sim¬ 
ulation  run  time  (higher  percentages  were  given  higher 
priority) . 

All  routines  were  processed  against  this  criteria  with  the  interim  results 
indicated  in  Table  1.  After  Air  Force  review,  an  ordered  list  was  developed 
(Table  2).  Finally,  a  Final  Prioritized  List,  grouping  models  interrelated 
or  similar  in  nature,  was  developed  and  is  depicted  in  Table  3. 
Enhancements  were  then  initiated  as  indicated  in  the  following  paragraphs. 
Efficiency 

The  efficiency  of  DMSS  routines  (executive,  models,  and  utilities) 
was  improved  by  decreasing  core  useage  and/or  execution  time.  The  following 
improvements  were  included  as  applicable: 
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TABLE  2 


ORDERED  LIST  FROM  THE  MATRIX  ARRANGED 
BY  TOTAL  SCORE 


AIRPLN 

TRAJEC  INU 

CALP  1  DIR  1 

LAND 

FCNAV  SCORE9  TACAN 

EARTH  HUDES 

SCEN  1 

BKGR3D  ILSI  MK82S 

CALLER 


LSR 

TRANS 

CNTRLS 

EXEC21 

INSTRM 

SUPER1 

ADC1 

ATM2 

CFDRAG 

DC  I  1 

PROPEL 

WIND 

ILIM 

AERO 

COCKPT 

EXECIN  1 
PAVPEN 

A7BLOK  Common 

1-These  are  all  executive  routines 


RADALT 
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TABLE  3 


FINAL  PRIORITIZED  LIST  GROUPING  THOSE  MODELS 
INTERRELATED/VERY  SIMILAR 
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DC  I 
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•  Delete  unused  subroutines,  variables,  and  lines  of  code. 

•  Use  integers  amd  smaller  arrays  wherever  feasible. 

•  Locate  the  innermost  loops  and  decrease  their  size. 

(This  section  of  code  is  executed  the  most  often  so 
cutting  size  will  decrease  both  execution  time  and  core 
useage. ) 

•  Make  operands  all  the  same  type  in  arithmetic  statements 
if  possible.  (This  will  decrease  conversions  needed 
between  data  types.) 

•  Define  data  to  end  on  word  or  byte  boundaries. 

•  Place  the  most  likely  true  first  in  conditional 
statements.  (For  example,  in  a  complex  .OR.,  put  the 
truest  first.  This  saves  multiple  compares.) 

•  Minimize  branching  on  conditions  as  much  as  possible. 

(Jump  only  on  least  possible  condition  so  as  to  execute 
the  shortest  path.) 

•  Check  out  table  searching  techniques.  (For  example,  is 
it  necessary  to  search  the  table  or  can  an  existing 
subscript  be  used  as  an  index?) 

•  Check  individual  routine  priority  and  scheduling  rates 
and  consider  reducing  if  quality  of  simulation  is 
unaffected . 

•  Isolate  overly  precise  calculations  and  relax  model 
accuracy  if  simulation  performance  is  not  degraded. 

In  addition  to  the  individual  model  enhancements,  the  restructing  of 
the  load  module  was  analyzed  so  that  only  essential  routines  will  be 
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core-resident  during  real-time  execution.  Appropriate  modifications  were 
then  incorporated. 

Portabi 1 ity 

Future  mission  requirements  were  reviewed  with  the  Air  Force  Program 
Manager  and  it  was  determined  which  computer  systems  were  being  contemplated 
as  potential  DMSS  hosts.  Principal  candidates  located  and  considered  during 
this  effort  were  the  PDP-11  and  VAX-11/780.  In  those  cases  where  these 
specific  computer  systems  were  identified  as  a  highly  likely  host  machine, 
the  feasibility  of  transferring  the  models  systems  was  assessed.  The 
results  of  this  analysis  were  utilizied  to  re-order  the  prioritization 
status  of  the  DMSS  routines.  The  following  enhancements  were  employed,  as 
required: 

•  Meaningful  explanatory  comments  were  inserted  to 
facilitate  future  modifications  and  maintenance. 

•  Esoteric,  obscure  coding  was  restructured  for  maintain¬ 
ability  if  efficiency  was  not  impaired,  or  was  annotated 
with  detailed  commentary. 

•  Hardware  dependent  interfacing  was  isolated  and  re¬ 
organized  into  a  small  set  of  subroutines. 

•  Top-down,  modularized  restructuring  was  accomplished 
where  possible. 

Coding  and  Checkout 

This  subtask  involved  modifications  to  the  routines  to  meet  the 
objectives  outlined  in  the  priorization  lists.  Changing  the  source  code 
(both  FORTRAN  and  DECsystem-10  assembler)  and  creating  new  code  (as 
required)  was  accomplished  by  the  project  team.  Subsequent  program  test  was 
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then  completed  for  all  modified  software.  A  change  log  file  was  created  in 
whicn  every  change  was  documented.  This  aided  in  the  final  documentation  of 
the  modules  and  prevented  repetition  of  errors.  All  changes  made  to  the 
existing  software  adhered  to  tne  techniques/standards  established  in  the 
Software  Management  Plan. 

The  following  three  different  libraries  of  the  DMSS  software  were 
maintained: 

(1)  Released  (a  copy  which  has  met  the  ATP); 

(2)  Working  (an  intermediate  version  for  the  testing  of 
changes  in  other  modules);  and 

(3)  Individual  (one  per  programmer  -  this  is  the  version 
undergoing  day-to-day  changes). 

The  modified  code  was  tested  via  previously  developed  test 
procedures  at  the  system  level  with  the  simulated  interface  acting  as  the 
mission  software  and  associated  hardware. 

Testing 

To  allow  errors  to  be  more  readily  isolated,  each  routine  was  tested 
individually  as  it  was  modified,  when  possible.  The  testing  ranged  from 
stand-alone  to  simulated  interface/functions  testing.  This  approach 
minimized  the  total  time  needed  in  the  final  testing  phase.  A  test  case  was 
created  for  each  routine  and  a  baseline  test  was  run  prior  to  changing  the 
code.  A  standard  then  existed  against  which  to  check  results.  This 
procedure  ensured  that  only  fully  operable  software  routines  were  delivered 
to  the  System  Integration  Branch  for  "re-acceptance"  and  system  integration 
testing. 

Formal  acceptance  testing  was  accomplished  in  accordance  with  test 


procedures  written  during  Task  5.  The  DMSS  software  was  then  tested  at  the 
system  level  with  the  mission  software. 

Maintenance 

DMSS  software  problems  were  documented  by  Air  Force  personnel, 
submitted  for  consideration,  and  corrected  as  approved  by  the  CCB.  The 
appropriate  documentation  was  also  modified  as  these  changes  were  made. 
Testing  of  modifications  was  accomplished  according  to  the  approved  test 
procedures.  Modifications  were  made  following  the  programming  standards 
established  in  the  Software  Management  Plan. 

TASK  3  -  DOCUMENTATION 

The  proposed  documentation  approach  was  an  integral  part  of  both  the 
development  and  enhancement  tasks,  and  resulted  in  the  delivery  of  the 
updated  Part  II  Specification  and  User's  Manual. 

Part  II  Specification 

The  Part  II  Specifications  for  the  VATS/Pave  Tack  and  Maverick 
models  were  developed  for  incorporation  into  the  existing  DMSS  Part  II 
Specification.  MIL-STD-483  and  MIL-STD-490  were  utilized  as  the  principal 
guidelines  throughout  the  documentation  effort.  The  final  format  and 

content  definition  was  coordinated  with  appropriate  Air  Force  and  DAIS 

contractor  personnel,  and  was  subject  to  review  and  approval  by  the  Air 

Force  Program  Manager.  These  tasks  were  accomplished  as  described  in  the 

following  subparagraphs. 

Development  of  New  Models  Specifications 

Since  approved  programming  and  documentation  practices  were 
enforced,  the  development  of  Part  II  Specification  inputs  covering  the  new 
models  was  accomplished  more  efficiently  than  upgrading  the  existing  DMSS 
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documentation.  A  software  development  notebook  was  maintained  for  each  new 
model  detailing  the  functional  capabilities,  interfaces,  design,  and  testing 
requirements  as  detailed  in  the  Software  Management  Plan. 

Particular  emphasis  was  placed  on  the  creation  of  program 
flowcharts.  Flowcharts  were  developed  with  enough  detail  to  directly 
reflect  the  coding  they  represent,  but  sufficiently  functional  to  obviate 
changes  for  every  code  change.  During  coding  and  checkout,  all  flowcharts 
were  updated  as  necessary  to  reflect  corrections  and  modifications  made 
during  debugging.  Finalized  versions  of  these  flowcharts  were  prepared  to  a 
level  of  detail  commensurate  with  that  used  in  the  Part  II  Specification. 
During  the  coding  process,  the  programmer  inserted  meaningful  comments  from 
the  flowchart  into  the  code. 

Revisions  of  Present  DMSS  Part  II  Specification 

The  orginal  Part  II  Specification  (SA  211  203),  dated  30  June  1977, 
was  reviewed  and  revisions  to  this  document  were  accomplished  as  follows: 

(1)  Revision  of  the  format,  organization,  and  content  to 
conform  to  the  guidelines  for  Part  II  Specifications 
established  by  MIL-STD-483  and  MIL-STD-490  as  approved 
by  the  Air  Force  Program  Manager. 

(2)  Detailed  review  of  each  model/module/utility  documen¬ 
tation  to  assure  modifications  in  the  Specification 
reflect  all  changes  due  to  optimization,  enhancement, 
and  restructuring  accomplished  during  Task  2. 

(3)  Development  and  incorporation  of  Part  II  Specifications 
for  sensor  models,  utilities,  etc.,  which  were  used  in 
the  current  DMSS  configuration  but  not  previously 
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documented . 


(4)  Incorporation  of  Part  II  Specifications  for  the  new 

models  developed  during  the  effort  (Maverick  and 
VATS/Pave  Tack) . 

Subtasks  (1)  through  (4)  were  accomplished  concurrently  with  the  new  models 
development  and  the  enhancement  tasks. 

The  existing  Part  II  Specification  was  analyzed  to  ascertain  if 
sufficient  information  was  available  to  meet  the  content  requirements  of 
MIL-STD-483  and  MIL-STD-490.  Individual  model/utility  specifications  found 
deficient  in  this  respect  were  noted.  Specification  upgrading  was  initiated 
with  those  routines  considered  to  be  of  lowest  priority  for  enhancement. 
This  was  accomplished  in  order  to  minimize  the  schedule  risk  associated  with 
the  revision  of  such  an  extensive  system. 

Concurrently  with  documentation  review,  software  personnel  began 
analyzing  and  modifying  DMSS  modules  assigned  highest  priority  for 
enhancement.  The  enhancement  of  each  routine  was  accomplished  by  assigning 
work  packages  to  software  personnel.  The  work  package  clearly  defined  the 
enhancement  task  to  include  the  addition  of  meaningful  source  code  comments; 
review  and  change  (or  preparation  of)  specification  data;  development  of  a 
test  plan;  and  the  actual  restructuring  and/or  optimization  of  the 
routine's  code.  Each  finished  work  package  was  reviewed  for  completeness  by 
the  Project  Manager.  The  DMSS  Part  II  Specification  was  formally  submitted 
to  the  Air  Force  for  final  review  and  distribution. 
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User's  Manual 


The  existing  User's  Manual (MA211203) ,  dated  30  June  1977,  was 
reviewed  for  conformance  to  D I -M- 3410  as  clarified  and  amplified  by  the 
guidelines  published  in  PA000105  (DAIS  Guidelines  for  Development  of  User's 
Manual),  and  the  following  five  categories  f  changes  were  recommended: 

(1)  Complete  reorganization  and  revision  of  the  User's 
Manual  to  more  closely  conform  with  DAIS  manual  format 
and  content  requirements,  and  to  allow  a 
non-software-oriented  user  to  operate  the  simulation 
with  minimal  assistance. 

(2)  Inclusion  of  sections  describing  Maverick 

and  VATS/Pave  Tack  model  and  currently  used  models  not 
prr  iously  documented. 

(3)  Deletion  of  sections  describing  models  no 

longer  utilized  in  the  current  DMSS  configuration. 

(4)  Deletion  of  informative  but  unnecessary  sections 
from  the  main  body  of  the  manual. 

(5)  Inclusion  of  more  user-oriented  information 

in  the  form  of  specific  examples  of  how  to  create  and 
run  typical  simulations,  starting  with  the  most  basic 
simulation  (which  would  include  the  minimum  number  of 
models)  and  including  an  advanced  simulation  (which 
would  include  the  number  of  models  commonly  used). 

The  updating  of  the  User's  Manual  was  accomplished  in  parallel  with 
the  updating  of  the  Part  II  Specification.  Individual  model 
enhancement/optimization  activities  had  little  effect  on  the  User's  Manual. 
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Upon  completion  of  the  DMSS  User's  Manual  update,  it  was  formally  submitted 
to  the  Air  Force  for  final  review  and  distribution. 

TASK  4  -  SOFTWARE  MANAGEMENT  PLAN 

The  Software  Management  Plan  defined  the  methodology  to  be  used  in 
developing  new  DMSS  software  and  in  maintaining  and  enhancing  existing  DMSS 
software.  It  covered  the  following  software  development  areas: 

•  Specification  of  performance  requirements; 

•  Formulation  of  preliminary  design  specifications 

and  top-level  flowcharts; 

•  Formulation  of  test  plans  and  test  procedures; 

•  Presentation  of  designs  for  formal  review; 

•  Coding  and  commenting  practices  and  standards' 

•  Testing,  formal  and  informal; 

•  Documentation  of  test  results; 

t  Documentation  of  software  and  revision  of  User's 
Manual  and  Part  II  Specification; 

•  Internal  configuration  control  procedures  and 
compatabi 1 ity  with  external  procedures;  and 

•  Detailed  contract  schedule. 

The  objecnve  of  the  Software  Management  Plan  was  to  ensure  the 
orderly  and  efficient  development  or  modification  of  DMSS  software.  The 
long  range  goal  of  the  plan  was  to  ensure  the  low  life  cycle  cost  of  the 
software,  and  to  make  it  easily  adaptable  and  transportable  so  as  to 
effectively  meet  future  simulation  requirements  of  DAIS  or  similar  programs. 

The  plan  required  full  use  of,  and  compatibl i 1 ity  with,  existing 
software  development  guidelines  already  available  within  the  Avionics 
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Laboratory.  The  plan  focused  on  the  procedures  to  be  used  internally  to 
develop  or  enhance  the  software,  since  these  methodologies  are  extremely 
important  if  efficient,  timely  delivery  of  software  and  documentation  is  to 
be  realized. 

The  Software  Management  Plan  was  basically  divided  into  two  sections 
reflecting  the  twofold  nature  of  the  OMSS  Software  Support  contract:  (1) 
development  of  new  software,  and  (2)  enhancement  of  existing  software. 
There  was  a  large  measure  of  commonality  between  the  management  requirements 
for  these  two  basic  tasks,  yet  sufficient  differences  existed  to  warrant 
separate  discussions. 

TASK  5  -  INTEGRATION  AND  TESTING 

The  goal  of  the  integration  and  testing  activities  was  to  ensure 
that  the  new  models  and  the  optimized  executive  and  models  perform  their 
respective  functions  in  a  precise  and  timely  manner.  Following  the  design 
and  coding  of  the  Maverick  and  VATS/Pave  Tack  models,  software  personnel 
were  responsible  for  the  integration  of  these  models  into  the  system  and 
subsequent  system  testing.  The  integration  and  testing  process  ensured  the 
compatibi 1 ity  of  the  models  with  their  respective  Interface  Control  Document 
descriptions. 

A  draft  Computer  Program  Test  Plan  was  prepared  for  each  new  model 
and  the  entire  DMSS  and  delivered  to  the  Air  Force  Program  Manager.  These 
documents  defined  the  test  requirements  necessary  to  verify  that  the  DMSS 
software  met  the  approved  performance  requirements.  Test  Reports  for  each 
new  model  and  the  total  DMSS  were  developed  based  upon  test  results 
delivered  to  the  Air  Force.  These  reports  primarily  addressed  the  test 
results  (expected  vs.  actual)  and  recommendations  for  future  action  based 
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upon  test  results.  The  types  of  testing  performed  are  discussed  in  the 
following  subparagraphs. 

Stand-Alone  Testing 

Module  specifications  were  analyzed  and  test  cases  identified  that 
would  exercise  the  module  not  only  at  the  extremes  but  across  its  dynamic 
range.  To  support  this  method  of  testing,  a  "test  driver"  designed  to 
exercise  the  module  with  preselected  test  cases  was  developed. 

Using  this  tool,  the  various  module  inputs  were  specified,  and  the 
outputs  of  the  module  monitored  as  a  function  of  time.  The  test  cases  were 
accessed  on  a  test  case  to  test  case  basis.  Each  test  case  contained  the 
input  values. 

Interface  and  Functional  Testing  (TFT) 

Each  enhanced  model  was  individually  tested  in  the  total  simulation 
system  by  being  linked  into  a  baselined  scenario-driven  system  allowing 
repeatability  of  the  flight  scenario.  The  outputs  of  the  module  were 
compared  to  a  file  of  baseline  outputs  by  printing  out  the  test  run  data  and 
the  compatible  baseline  data  for  visual  comparison  by  the  IFT  test  team. 
Acceptance  Test  Procedure  (ATP) 

After  all  the  models  successfully  passed  IFT,  the  DMSS  was  rebuilt 
with  all  the  enhanced  models  included.  This  testing  was  the  responsibility 
of  the  System  Integration  and  Test  Coordination  (SITC)  contractor  with  SCI 
providing  assistance  as  needed.  The  ATP  consisted  of  running  the  enhanced 
DMSS  through  the  standard  DAIS  system  test  and  paying  particular  notice  to 
the  options/selections  that  are  DMSS  dependent.  The  ITB  had  to  be  fully 
operational  for  this  testing.  After  the  enhanced  DMSS  passed  ATP  it  was 
accepted  for  distribution. 
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TASK  6  -  ENGINEERING  SUPPORT  SERVICES 

Throughout  the  term  of  the  effort,  engineering  support  services  were 
provided  on  an  as  required  basis  in  the  following  areas: 

•  Development  and  documentation  of  a  Global  Cross 
Reference  System  (SETUSE); 

•  INU  model  enhancement  consultation; 

•  SORT  Program  User's  Manual  development; 

•  Enhancement  task  consulting; 

t  New  Models  Development  Task  consulting;  and 

•  Airplane  model  enhancement  consulting. 

TASK  7  -  LIAISON  AND  COORDINATION 

In  a  program  of  the  size,  complexity  and  scope  of  the  DMSS  Software 
Support  Effort,  liaison  and  coordination  with  the  Air  Force  user,  technical 
and  management  is  vital  to  overall  project  success.  Some  of  the  specific 
persons  and  organizations  with  whom  interfacing  was  required  included: 

•  The  SITC  contractor  and  the  DAIS  Program  Branch  to 
ensure  that  the  design  of  the  new  models  adhere  to 
overal 1  DAIS  goals . 

•  The  Configuration  Control  Board  (CCB)  and  users  to  main¬ 
tain  the  software  and  enhancements. 

•  AVSAIL  personnel  for  development  of  COMMON  block 
standards,  etc. 

•  Cognizant  individuals,  who  have  impacts  on  the 
Preliminary  Design  Reviews  (PDR)  and  Critical 
Design  Reviews  (CDR),  for  critiques  and  inputs. 


36 


Figure  6 

Liaison  and  Coordination 


The  SCI  Project  Manager  has  responsible  for  ensuring  that  all 
activities  were  coordinated.  On  a  formal  basis,  status  meetings  were  held 
to  be  certain  that  all  ideas  and  opinions  were  available  to  the  various 
groups.  The  format,  scheduling  and  agendas  were  coordinated  with  the  Air 
Force  Program  Manager.  Figure  6  depicts  the  liaison  and  coordination  which 
was  required  during  this  effort. 

TASK  8  -  TRAINING 

The  training  task  was  considered  to  be  an  important  element  of  the 
DMSS  Software  Support  Contract  since  all  personnel  associated  with  the 
system  should  possess  the  necessary  knowledge  and  skills  to  use  it 
effectively.  Features  of  the  training  task  included: 

•  Coordination  with  the  AF  Program  Manager  and  other 
cognizant  Air  Fe^ce  and  contractor  personnel  to  identify 
training  requirements  (i.e.,  level  of  detail,  number  of 
class  participants,  scheduling,  etc.), 

•  Development  of  detailed  lectures,  examples  and 
presentation  materials  designed  to  fully  acquaint  the 
students  with  the  subject  matter.  Presentations, 
classroom  lectures  and  examples  were  submitted  to  the 
Air  Force  Program  Manager  for  review.  Classroom 
materials  were  distributed  on  the  first  day  of  class  for 
each  course. 

The  Maverick  Missile  and  VATS/Pave  Tack  course  and  the  DMSS 
Optimization/Enhancement  course  are  detailed  as  follows. 

Maverick  Missile  and  VATS/Pave  Tack  Course 

The  Maverick  Missle  and  VATS/Pave  Tack  course  were  scheduled  after 
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the  integration  and  testing  of  these  new  models  into  the  DMSS.  The  training 
topics  and  materials  included: 

•  Detailed  description  of  each  model,  its  major 
objectives  and  underlying  (simplifying)  assumptions. 

•  Review  of  the  design  specifications. 

•  Development  tradeoffs,  size  and  timing  constraints 
considered  during  the  design  stage. 

•  Detailed  flowchart,  input,  output  and  interface 
descriptions  and  narrative  descriptions  as  presented  in 
the  Part  II  Specification  and  User's  Manual. 

•  Detailed  description  of  model  operation  including 
organization  and  definition  of  variables  and  other  data 
structures. 

Operation  of  DMSS 

The  operation  of  the  enhanced  T  training  course  was  scheduled 
after  the  executive  optimization  and  models  enhancement  tasking  was 
completed.  The  training  topics  included: 

•  DMSS  Overview 

•  Executive  Software 

•  Sensor  Models 

•  SLU/Stores  Models 

•  Environment/Aircraft  Models 

•  Utility  Software 

•  DMSS  Interfaces 

-  DAIS  Mission  Software 

-  Controls  and  Backup  Instrument  System 
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-  DECsystem-10  0MA-10  Window 


Training  materials  included  the  analysis  of  executive  software  and  models 
chosen  for  enhancement  and  the  User's  Manual. 

TASK  9  -  PROGRAM  MANAGEMENT 

Program  management  was  responsible  for  technical  and  financial 
guideline  of  the  project  throughout  its  life  cycle.  Personnel  assignments 
and  reporting  procedures  were  also  a  principal  consideration  of  the  effort. 
A  Contract  Work  Breakdown  Structure  (CWBS)  was  prepared,  and  updated  during 
contract  performance  to  reflect  changes  in  the  scope  of  effort,  requirements 
definition,  or  alternative  approaches.  All  updates  were  coordinated  with 
the  DAIS  Program  Office  and  subject  to  approval  of  the  DMSS  Program  Manager, 
the  Air  Force  Program  Manager,  and  the  DAIS  Procuring  Contract  Office  (PCO). 
The  following  subparagraphs  detail  program  management  reporting  against  the 
CWBS. 
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Physical  Configuration  Audit 


Upon  completion  of  the  DMSS  optimization  (including  integration  of 
the  new  models  and  successful  ITB  testing),  a  Physical  Configuration  Audit 
was  conducted  in  accordance  with  the  requirements  of  the  DAIS  Configuration 
Management  Plan.  The  audit  included  a  detailed  review  of  format,  content, 
and  completeness  of  the  DMSS  Part  II  Specification,  User's  Manual,  and  Test 
Reports. 

SUMMARY 

Successful  completion  of  the  DMSS  Software  Support  contract  was 
predicated  principally  on  three  factors: 

(1)  The  detailed  and  phased  approach  outlined  in  this  Section; 

(2)  The  development  of,  and  adherence  to,  a  comprehensive  Software 
Management  Plan  approved  by  the  Air  Force;  and 

(3)  Constant  liaison  and  coordination  with  the  Air  Force  throughout 
the  entire  effort. 

Based  upon  some  modifications  to  the  projected  schedule  and 
technical  tasking  flow,  deviations  from  the  proposed  approach  occurred 
during  the  effort.  In  order  to  highlight  these  deviations  and  the 
associated  rationale,  they  have  been  made  the  subject  of  the  next  section  of 
this  report. 


SECTION  IV 

DEVIATIONS/MODIFICATIONS 

INTRODUCTION 

The  previous  section  described  the  technical  approach  for  the  DMSS 
Software  Support  effort.  This  section  enumerates  the  deviations  from,  and 
modifications  to,  the  original  approach  and  the  supporting  rationale  for 
these  changes. 

FORTRAN/RATFOR  ANALYSIS 

As  the  principal  thrusts  of  the  DMSS  effort  were  the 
transportability  and  enhancement  of  the  models,  top-down  structuring 
techniques  were  used.  Top-down  structuring  improves  maintainability  because 
it  is  readily  understood  by  system  maintenance  personnel.  However, 
FORTRAN-10  does  not  support  structured  constructs  of  IF-THEN-ELSE,  WHILE, 
and  REPEAT-UNTIL,  thus  the  structured  FORTRAN  preprocessor  RATFOR  was 
investigated  for  possible  use.  RATFOR  converts  structured  FORTRAN-like 
programs  i-nto  ANSI  FORTRAN  for  compilation. 

One  of  the  enhancement  models  RADALT,  Radar  Altimeter,  was  optimized 
in  FORTRAN-10  and  RATFOR.  The  memory  utilization  for  the  RATFOR  version  was 
435  words  while  the  FORTRAN  version  was  428  words  (an  increase  of  less  than 
2%).  The  readability  and  understandabi 1 ity  of  the  RATFOR  version  was  very 
favorable.  The  RATFOR  preprocessor  was  written  in  FORTRAN  IV  (so  it  could 
be  transported  to  another  computer)  and  the  Digital  Equipment  Computer  User 
Society  (DECUS)  also  can  supply  a  version  of  RATFOR.  The  decision  was  then 
made  to  restructure  all  model  routines  into  RATFOR.  This  decision  had  no 
schedule  or  level-of  effort  impact  on  the  DMSS  Software  Support  Project. 
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GLOBAL  CROSS  REFERENCE 


Because  the  global  variable  usage  was  an  intricate  part  of  DMSS  and 
it  was  difficult  to  track  down  the  routines  using  different  global 
variables,  a  global  cross  reference  analyzer  was  developed  as  part  of  the 
engineering  support  task.  This  program  listed  out  all  global  variables  used 
by  the  subject  subroutines  and  then  specifies  if  the  variable  was  set,  used, 
or  passed  as  a  parameter. 

COMMON  BLOCK  STANDARDS 

As  part  of  the  liaison  task,  an  SCI  representative  attended  meetings 
of  the  AVSAIL  COMMON  Block  Standards  Committee.  The  results  of  these 
meetings  were  documented  in  IE  004  1000  (COMMON  Block  Standards  for  AVSAIL 
Avionics  Models).  After  receiving  Air  Force  concurrence  to  increase  the 
scope  of  the  DMSS  Software  Support  effort,  the  enhancement  task  renamed  all 
variables  used  to  reflect  the  COMMON  Block  Variable  Names  standards.  These 
standards  required  a  reorganization  of  the  variables  within  the  COMMON 
Blocks  which  was  accomplished  as  part  of  this  effort. 

ENHANCEMENT  FOR  ASP 

In  June,  1980  for  the  transition  of  DAIS  technology  to  the 
Integrated  Digital  Avionics  (IDA)  program,  the  scope  of  the  enhancement  task 
was  increased  to  include  the  rehosting  of  some  of  the  DMSS  software  to 
System  Engineering  Analysis  Facility  (SEAFAC)  at  ASD.  This  rehosting 
consisted  of  transferring  the  Run-Time  Monitoring  Program  (M0NI)  to  a 
PDP-11/55,  transferring  the  Post  Run  Analysis  routines  onto  a  VAX-11/780, 
transferring  the  Checkpoint/Reset  routines  onto  a  VAX-11/780,  and  creating  a 
guideline  for  development  of  Interface  Control  Documents. 

The  M0NI  program  displayed  in  real-time  specified  bus  messages  and 
simulation  variables.  The  Post  Run  Analysis  software  tabulated  and  plotted 
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data  that  was  logged  during  the  real-time  simulation.  This  routine  can  be 
executed  anytime  after  the  simulation  has  been  completed.  The 
Checkpoint/Reset  routines  allows  a  simulation  user  to  take  a  checkpoint  of 
data  anytime  during  the  simulation,  while  the  reset  portion  will 
reinitialize  the  simulation  to  any  specified  checkpoint.  The  Interface 
Control  Document  specifies  variables  and  bus  message  formats  for  that  data 
which  is  transferred  from  one  hardware  system  to  another  in  the  real-time 
simulation. 

The  following  documents  were  delivered  to  SEAFAC: 

•  Run-Time  Monitoring  Program  (MONI)  Part  II  Specification; 

•  MONI  User's  Guide; 

•  Post-Run  Analysis  Part  II  Specification; 

•  Post-Run  Analysis  User's  Guide; 

t  Checkpoint/Reset  Part  II  Specification; 

•  Checkpoint/Reset  User's  Guide;  and 

•  Interface  Control  Documents  (ICO)  Guidelines. 

The  test  plans  for  each  of  the  software  products  were  included  in  section 
4.0  of  the  respective  Part  II  Specification. 

INTEGRATED  TEST  BED 

Some  enhanced  models  were  ready  for  testing  in  April,  However,  in 
spending  10  hours  on  attempting  Integration  and  Functional  Testing  ( I FT )  on 
the  DAIS  Integrated  Test  Bed  (ITB)  and  only  accomplishing  2  hours  of  actual 
testing,  it  was  decided  to  change  the  planned  testing  approach.  SCI  would 
still  conduct  the  Stand  Alone  Testing  and  Preliminary  Qualification  Tests 
(PQT)  with  the  Air  Force  Program  Manager  and  SITC  reviewing  the  results. 
With  unreliable  hardware  in  the  ITB,  it  was  more  efficient  for  the  Air  Force 
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and  SITC  to  conduct  the  IFT  with  SCI  personnel  being  called  upon  only  for 
complex  problems.  Working  in  this  mode  for  several  months,  about  one  half 
of  the  models  were  tested.  Finally  the  hardware  system  was  sufficiently 
reliable  to  allow  SCI  and  Air  Force  personnel  to  spend  20  hours  in  one  week 
during  November  for  IFTs  on  the  last  half  of  the  enhanced  models. 

The  ITB  unreliability  was  due  to  inconsistencies  of  the  following 
hardware: 

1)  Cockpit  Controls  and  Displays 

•  Not  initializing  correctly;  and 

•  Locking-up  in  the  middle  of  testing. 

2)  DECsystem-10 

•  Having  some  memory  off-line; 

•  Allocating  DMA  channels;  and 

•  Slave  processor  has  instruction  problem 
(DMSS  must  run  on  the  slave). 

3)  On-board  Processors 

•  Problems  with  BCIU; 

t  Booting  the  processors;  and 

•  Problems  with  power  supply. 

Occasionally,  the  other  hardware  which  interfaces  with  the  ITB  had 
minor  operating  difficulties.  They  were  the  Evans  &  Sutherland  Picture 
System  and  the  Simulated  Subsystem  Data  Formatter  (SSDF).  Unfortunately, 
the  hardware  unreliability  impacted  the  ATP  to  the  point  where  the  ATP- has 
not  to  date  been  performed.  All  of  the  enhanced  models  have  individually 
been  tested  on  the  full  ITB  and  some  loads  of  various  enhanced  models 
combinations  have  been  tested. 
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These  hardware  problems  also  impacted  the  enhanced  DMSS  training. 
Actual  exercises  on  the  DMSS  execution  could  not  be  presented  for  the 
student's  benefit. 

SYSTEM  HARDWARE 

SCI  personnel  also  found  some  difficulties  in  using  the  DECsystem-10 
for  the  models  enhancement.  This  was  primarily  due  to  terminal  response 
time  during  normal  working  hours.  The  SCI  in-house  PDP-11/34  was  used  for 
development  and  testing  of  all  of  the  enhanced  models.  Only  portions  of 
code  handling  the  bit  manipulations  could  not  be  fully  tested  on  the  PDP-11. 
This  approach  to  computer  usage  increased  the  productivity  of  the 
enhancement  and  new  models  development  staff  as  it  cut  down  the  travel  time 
needed  for  picking  up  listings  or  for  using  a  high  speed  terminal,  and  it 
eliminated  unproductive  time  from  DECsystem-10  periods  of  unreliability  and 
down-time.  The  PDP-11/34  was  used  as  a  word  processor  for  the  production  of 
the  Part  II  Specification  and  other  DMSS  documentation.  This  usage  reduced 
the  amount  of  re-typing  and  proofing, 
f LOW  DIAGRAM  GENERATOR 

Also  in  support  of  the  Part  II  Specification  production,  an 
automatic  flow  diagram  program  was  utilized  by  SCI  on  the  PDP-11/34.  This 
program  took  a  RATFOR  source  code  routine  and  created  a  structured  flowchart 
which  was  produced  on  a  Printronix  dot-matrix  printer.  The  total  amount  of 
PDP-li/34  computer  time  used  in  support  of  the  DMSS  effort  for  both  model 
deve lopent/enhancement  and  for  word  processing  is  depicted  in  Figure  7. 
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Hours 

CPU  Units 

Jun  79 

4.5 

400 

Jul  79 

9.3 

480 

Aug  79 

15.0 

7,000 

Sep  79 

29.6 

16,500 

Oct  79 

219.5 

499,000 

Nov  79 

452.4 

1,167,600 

Dec  79 

211.1 

1,208,340 

Jan  80 

90.0 

193,700 

Feb  80 

133.7 

232,038 

Mar  80 

56.0 

896,561 

Apr  80 

187.2 

1,171,787 

May  80 

201.7 

758,810 

Jun  80 

229,9 

873,767 

Jul  80 

357.4 

768,939 

Aug  80 

76.3 

84,072 

Sep  80 

324.0 

388,858 

Oct  80 

2,710.9 

573,398 

Nov  80* 

1,000.0 

240,000 

*  Fstimated 


Figure  7 

SCI  PDP-11/34  DMSS  Usage 
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SECTION  V 


OBSERVATIONS  AND  RECOMMENDATIONS 

PERSON  HOURS 

At  the  request  of  the  Air  Force  and  for  use  in  future  estimates,  the 
following  personhours  expended  for  the  new  models  development  (from  design 
through  PQT)  are  presented.  For  the  Maverick  Model,  660  hours  of  Senior 
Systems  Analyst  time  and  68  hours  of  typing/drafting  support  for  the 
preparation  of  design  review  packages  and  documentation.  For  the  VATS/PAVE 
TACK  Mcdel  it  took  604  hours  of  Senior  System  Analyst  time  and  60  hours  of 
typing/drafting  supporting. 

There  were  a  total  of  1320  hours  of  Senior  System  Analyst  time  and 
1100  hours  of  Programmer  time  expended  during  the  models  enhancement  task. 
This  time  did  not  include  IFT  time  which  was  considered  part  of  Task  5 
(Testing).  A  total  of  22  major  models  were  enhanced  under  this  effort. 
REVIEW  MEETING  PREPARATION 

SCI  recommends  that  the  time  between  delivery  of  design  review 
packages  and  the  actual  review  be  decreased.  The  existing  periods  cause  the 
new  model  developer  to  absorb  approximately  2  to  4  weeks  of  relatively 
non-productive  time  when  awaiting  the  review. 

SOFTWARE  DEVELOPMENT  NOTEBOOKS 

SCI  maintained  software  development  notebooks  for  each  new  and 
enhanced  model.  It  is  recommended  that  these  notebooks  should  have  stricter 
review  by  the  SCI  Program  Manager  for  completeness  and  consistency. 
DOCUMENTATION 

The  Part  II  Specification  section  for  each  individual  model  should 
have  been  finalized  as  soon  as  that  model  passed  PQT.  There  were  only  minor 
changes  made  to  the  routines  during  IFT  and  the  documentation  should  be 
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finalized  while  the  model  is  still  fresh  in  the  enhancer's  mind. 
Documentation  schedules  should  be  strictly  adhered  to  during  future  efforts. 
FINAL  RESULTS 

Improvements  were  made  in  the  core  useage  and  execution  times  of  the 
DMSS.  The  load  module  decreased  from  97K  words  to  68K  words  (a  decrease  of 
27%).  The  size  of  COMMON  was  changed  from  21K  words  to  15K  words  (29% 
decrease).  The  time  required  for  loading  and  locking  the  load  module  Into 
core  decreased  from  an  average  of  64.5  seconds  to  about  42  seconds  (36% 
improvement).  These  changes  should  favorably  influence  many  possible  users 
of  the  DMSS. 

FUTURE  CONSIDERATIONS 

There  are  many  utility,  data  logging,  and  real-time  assignment 
routines  within  DMSS  which  are  inefficient  and  poorly  designed  and  coded. 
These  would  be  greatly  improved  with  code  enhancement  and  conformation  to 
naming  standards. 

It  is  also  suggested  that  the  DMSS  be  transported  to  one  of  the 
existing  PDP-lls  in  the  AVSAIL  facility.  If  it  is  possible  to  effectively 
run  the  models  on  a  PDP-11  the  reliability  problems  of  the  DECsystem-10 
could  be  ignored  for  ITB  system  testing. 
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